Every plant running high-mix schedules has the same conversation eventually: changeovers are eating availability, and nobody can say exactly where the time goes. The instinct is to bring in a SMED consultant with a stopwatch and a clipboard, watch three changeovers, and get a report. That works, but it’s a snapshot — three changeovers on a good day, on one line, with an audience watching. Your MES, if it’s already tracking downtime, is sitting on the infrastructure to capture every changeover, on every line, every shift, forever. Most plants just aren’t using it that way. They log changeovers as one generic downtime reason code — “Changeover,” one bucket, one duration — and then wonder why the Pareto chart never gets more specific than “changeovers are bad.”
Here’s how to fix that without buying an engagement: build a real changeover state model into the MES, instrument the sub-steps, and let the data do what a stopwatch study only samples.
Why the single downtime code fails you
A generic “Changeover” reason code answers exactly one question: how much total time did changeovers cost you. It cannot tell you whether the bottleneck is waiting for the incoming material, physical tool exchange, fixture adjustment, first-piece inspection, or waiting for a supervisor to release the line. Those have completely different fixes — kitting, tooling design, poka-yoke fixtures, delegated release authority — and you can’t prioritize any of them from one aggregate number. If your OEE dashboard shows availability loss but your changeover data can’t be broken into sub-steps, you’re not tracking changeovers. You’re tracking that changeovers happened.
Step 1: Define an explicit changeover state, separate from “down”
Changeover is not the same thing as a fault or a starved/blocked condition, and treating it as just another downtime reason flattens the analysis before it starts. In your state model, changeover should be its own equipment or line state — distinct from Running, Faulted, Idle, and Blocked — with a clear entry condition and a clear exit condition tied to first good part or first accepted part, not just “machine moving again.”
This matters for ISA-95 alignment too: if you’re rolling this data up into enterprise reporting, changeover needs to be a recognized operational state, not a footnote inside downtime, so it reports consistently as a planned-but-costly event rather than noise mixed in with unplanned stops.
Sub-states, not just a start and stop timestamp
The real value comes from breaking changeover into sub-steps and timestamping each transition. A reasonably universal structure looks like this:
- Last good part (previous run) — the true zero point, captured automatically from production counts, not operator entry.
- Teardown start / teardown complete — old tooling, fixtures, or recipe removed.
- Changeover setup start — new tooling, material, or fixture staged and installed.
- Adjustment / trial run — machine running but not yet validated (this is where SMED analysis usually finds the most external-vs-internal setup waste).
- First piece inspection start / complete — quality sign-off, often a hidden time sink nobody counts as “changeover.”
- First good part (new run) — the true end point.
Six timestamps, most of them derivable from equipment state changes and production counters rather than operator button presses. That’s the difference between a stopwatch study and a state machine: the clock doesn’t rely on someone remembering to click a button at exactly the right moment.
Step 2: Reason codes that map to SMED categories, not vague labels
SMED’s whole premise is separating internal setup (must be done with the machine stopped) from external setup (can be done while it’s still running the prior job). Your reason codes should be built around that distinction from day one, not retrofitted later. Practical categories: material staging, tooling exchange, fixture/jig change, recipe/parameter load, cleaning/purge, first article inspection, and waiting-for-resource (operator, forklift, quality tech, supervisor release). That last one deserves its own code — “waiting for resource” during a changeover is almost always an external-setup opportunity hiding in plain sight, and it never shows up if it’s lumped into generic changeover time.
Step 3: Get the “changeover start” trigger right — this is where projects go sideways
The most common failure mode isn’t the dashboard. It’s an ambiguous start trigger that quietly corrupts every duration you calculate downstream.
- Don’t rely on an operator button press as the sole start signal. Operators press it late, forget it, or press it early to pad the changeover allowance if there’s any perception that changeover time reflects on them personally. Anchor the start to the last good part off the previous job whenever your counting system supports it — it’s objective and it can’t be gamed.
- Watch for “changeover” masking other losses. If a machine sits idle waiting for the next job’s material because scheduling or kitting fell behind, that’s a logistics loss, not a mechanical setup loss — but it’ll get coded as changeover time if your state model doesn’t separate “waiting to start” from “actively changing over.” Give it its own state or sub-code.
- Beware combined changeovers. A line that’s swapping product and doing a scheduled minor PM at the same time will blow up your averages if it’s not flagged separately. Add a flag or modifier, don’t create a whole new reason-code tree for every combination.
The gaming problem is real — design around it, don’t just police it
Any manual timestamp an operator controls is a timestamp an operator can influence, consciously or not. The fix isn’t a memo about honesty; it’s minimizing manual entries. Pull as many transition timestamps as possible from PLC state changes, part counters, and recipe-load confirmations. Reserve operator prompts for things a machine genuinely can’t sense — “tooling swap complete, starting fixture adjustment” — and keep those prompts short, single-tap, and displayed on the HMI at the moment the transition actually happens, not buried in an end-of-shift form.
Step 4: Turn the captured data into a standard changeover dashboard
Once you have timestamped sub-steps and SMED-aligned reason codes, the dashboard mostly builds itself:
- Changeover duration distribution by product pair (this changeover-to-that changeover), not just a plant-wide average — mix-driven variation is often the real story.
- Sub-step Pareto showing where time actually concentrates across dozens or hundreds of changeovers, not three observed ones.
- Internal vs. external setup split, tracked over time, so you can see whether process changes are actually shifting work off the clock.
- Tie-in to OEE availability loss — changeover state should feed directly into your availability calculation as its own bucket, separate from unplanned downtime, so leadership can see it as a scheduling and process-design problem rather than a maintenance problem.
Done right, this replaces the one-time stopwatch study with a living dataset. You get every changeover, on every shift, across every product pairing — which is exactly the sample size SMED analysis needs and a clipboard study can never provide. The consulting engagement still has value for training your team on SMED methodology itself. It’s just no longer the only way to get the data that methodology needs to work on.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
